Content Pre-Render and Pre-Fetch Techniques

ABSTRACT

Content pre-render and pre-fetch techniques are described. In one or more implementations, a likelihood is predicted of subsequent navigation to content associated with a network address based at least in part on monitored navigation performed by a computing device to one or more network addresses. A determination is then made whether to cause the computing device to pre-fetch and pre-render the content based at least in part on the prediction.

BACKGROUND

Users may spend a significant amount of time navigating between network addresses by using a computing device, such as to “surf the web.” For example, users may navigate between a variety of different webpages provided via a variety of different websites to view and interact with content of interest.

To draw users, the content available from the network addresses continues to provide an ever increasing richness for viewing by users. This may include use of rich graphics, dynamic scripts, animations, audio, streaming content, and so on. However, the richness of this content may cause delays in navigation to access these network addresses, which may decrease a user's experience and therefore counteract the purpose of a service provider in making this content available to the users.

SUMMARY

Content pre-render and pre-fetch techniques are described. In one or more implementations, a likelihood is predicted of subsequent navigation to content associated with a network address based at least in part on monitored navigation performed by a computing device to one or more network addresses. A determination is then made whether to cause the computing device to pre-fetch and pre-render the content based at least in part on the prediction.

In one or more implementations, a system includes one or more modules implemented at least partially in hardware. The one or more modules are configured to perform operations that include computing a confidence score indicating a relative likelihood of subsequent navigation to content associated with a network address based at least in part on monitored navigation performed by a computing device to one or more network addresses. Responsive to a determination that the confidence score meets a pre-render threshold for the subsequent navigation, the content associated with the network address is caused to be pre-fetched and pre-rendered by the computing device. Responsive to a determination that the confidence score meets a pre-fetch threshold for the subsequent navigation but does not meet the pre-render threshold for the subsequent navigation, the content associated with the network address is caused to be pre-fetched but not pre-rendered by the computing device.

In one or more implementations, a system includes one or more modules implemented at least partially in hardware. The one or more modules are configured to perform operations that include generating navigation data based on monitored navigation performed by a plurality of different computing devices to access a plurality of different network addresses and exposing the navigation data for use by a computing device to predict subsequent navigation by the computing device to one or more network addresses, at least part of the predicted navigation not involving a link included in a current content item accessed by the computing device.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different instances in the description and the figures may indicate similar or identical items. Entities represented in the figures may be indicative of one or more entities and thus reference may be made interchangeably to single or plural forms of the entities in the discussion.

FIG. 1 is an illustration of an environment in an example implementation that is operable to perform content pre-render and pre-fetch techniques.

FIG. 2 depicts an example of a system in which interaction between the computing device and the service provider is shown.

FIG. 3 depicts a system in an example implementation in which a confidence score is leveraged to determine whether to pre-render and/or pre-fetch content from a network address.

FIG. 4 depicts an example of use of pre-rendered content in a browser of a computing device.

FIG. 5 is a flow diagram depicting a procedure in an example implementation in which data is collected from a plurality of computing devices and used to generate navigation data that is exposed to predict subsequent navigation.

FIG. 6 is a flow diagram depicting a procedure in an example implementation in which a prediction of a likelihood of subsequent navigation to particular network addresses is utilized to determine whether to pre-fetch and pre-render content available via the particular network address.

FIG. 7 illustrates an example system that includes the computing device as described with reference to FIG. 1.

FIG. 8 illustrates various components of an example device that can be implemented as any type of computing device as described with reference to FIGS. 1-7 to implement embodiments of the techniques described herein.

DETAILED DESCRIPTION Overview

A user experience involved in navigation between network addresses (e.g., webpages) may be improved by pre-rendering content located at network addresses associated with likely user navigation. For example, to pre-render a web page, a browser or other web-enabled application may download resources associated with the content of the page and then construct that page. Therefore, when the user navigates to the pre-rendered webpage, the page may be displayed without waiting for the content to be obtained and rendered as these operations have already occurred.

However, pre-rendering of content may be considered a relatively expensive operation in terms of computing device resource usage. Therefore, techniques are described herein in which a likelihood that a user will cause a computing device to navigate to a particular network address may be used as a basis to determine whether to pre-render content available via a network address. For example, a confidence score may be computed as part of a prediction for navigation to a particular website. This computation may be based on a variety of factors, such use of navigation data that describes a sequence of navigations made by other users in a similar situation. Therefore, this group browsing history may be used to determine a likely destination as well as a confidence score detailing how likely that navigation is to occur.

If the confidence score indicates a relatively high likelihood (e.g., through comparison with a pre-render threshold), the content may be pre-fetched and pre-rendered by the computing device. In another instance, the confidence score may indicate that although the navigation is likely, the navigation is not likely enough to justify pre-rendering of the content, such as to meet a pre-fetch threshold but not the pre-render threshold. In such an instance, the content may be pre-fetched but not pre-rendered, e.g., the content is downloaded. In this way, the computing device may leverage these relative likelihoods to support increased functionality and efficiency, such as to support use of a “flip ahead” function in a browser. A variety of other examples are also contemplated, further discussion of which may be found in relation to the following sections.

In the following discussion, an example environment is first described that may employ the techniques described herein. Example procedures are then described which may be performed in the example environment as well as other environments. Consequently, performance of the example procedures is not limited to the example environment and the example environment is not limited to performance of the example procedures.

Example Environment

FIG. 1 is an illustration of an environment 100 in an example implementation that is operable to employ techniques described herein. The illustrated environment 100 includes a computing device 102, a service provider 104, and one or more network addresses 106, each of which are communicatively coupled, one to another, via a network 108. The computing device 102 as well as computing devices that may implement the service provider 104 and network addresses 106 may be configured in a variety of ways.

For example, a computing device may be configured as a computer that is capable of communicating over the network 108, such as a desktop computer, a mobile station, an entertainment appliance, a set-top box communicatively coupled to a display device, a wireless phone, a game console, and so forth. Thus, the computing device 102 may range from full resource devices with substantial memory and processor resources (e.g., personal computers, game consoles) to a low-resource device with limited memory and/or processing resources (e.g., traditional set-top boxes, hand-held game consoles). Additionally, a computing device may be representative of a plurality of different devices, such as multiple servers utilized by a business to perform operations such as by the service provider 104 or network addresses 106, a remote control and set-top box combination, an image capture device and a game console configured to capture gestures, and so on.

Although the network 108 is illustrated as the Internet, the network may assume a wide variety of configurations. For example, the network 108 may include a wide area network (WAN), a local area network (LAN), a wireless network, a public telephone network, an intranet, and so on. Further, although a single network 108 is shown, the network 108 may be representative of a plurality of networks.

The computing device 102 is further illustrated as including a communication module 110. The communication module 110 is representative of functionality that is configured to interact with the network address 106 and/or the service provider 104 via the network 108. As such, the communication module 110 may be configured in a variety of ways. For example, the communication module 110 may be configured as a browser that is configured to “surf the web.” The communication module 110 may also be configured as part of a network-enabled application (e.g., a web-enabled app), a plug-in module, part of an operating system, and so on. Thus, network access functionality represented by the communication module 110 may be implemented in a variety of different ways.

The communication module 110 is also illustrated as including a navigation monitoring module 112. The navigation monitoring module 112 is representative of functionality to monitor navigation of the communication module 110 (and thus the computing device 102) to interact with the different network addresses 106, e.g., to access content via the network addresses 106. This may include generating data that describes a sequence of interaction with the network addresses 106, a context regarding those interactions, and so on.

The navigation monitoring module 112, for instance, may monitor a navigation sequence that involves selection of a favorite network address (e.g., website) in a browser, selection of a link within a webpage provided by that website, navigation to another website that involves typing in a network address 106, and so on. Further, this monitored navigation may include data describing a context of the navigation, such as a time of day, day of week, month, how the access was performed (e.g., selection of a link, typing of an address, search result), and so forth.

Data obtained from this monitored interaction may then be provided to a navigation manager module 114 of the service provider 104. The navigation manager module 114 is representative of functionality to obtain and manage data obtained from a plurality of computing devices that describes monitored navigation. This data may be leveraged in a variety of ways, such as a “group history” that describes navigation by the plurality of computing devices. This group history may then be used to support a variety of different functionality, such as to predict “to where” subsequent navigation that is performed by the computing device 102 will occur.

The navigation manager module 114, for instance, may be configured to generate navigation data 116 that is maintained in storage 118 associated with the service provider 104. This navigation data 116 may then be communicated to the computing device 102 for use by a navigation prediction module 120. The navigation prediction module 120 is representative of functionality to predict likely subsequent navigation by a computing device 102 and thus may leverage the navigation data 116 to make this prediction, further discussion of which may be found in the discussion of FIG. 2.

Further, as a part of making the prediction, the navigation prediction module 120 may compute an amount of confidence in the prediction, i.e., a confidence score. Thus, a determination may be made as to which actions are to be performed based on the amount of confidence in the prediction, further discussion of which may be found in relation to FIG. 3.

FIG. 2 depicts an example of a system 200 in which interaction between the computing device 102 and the service provider 104 is shown. As stated above, the navigation monitoring module 112 may be configured to monitor navigation performed by the communication module 110. This data may then be provided as a navigation history 202 to a navigation manager module 114 of the service provider 104. For example, a user of the computing device 102 may “opt in” to sharing of this information with the service provider 104 as part of the prediction functionality described herein. The navigation history 202 may then be provided, which may describe network addresses accessed by the computing device 102 as well as a context of that access as described above.

The navigation manager module 114 may then collect this data in storage 118 from a plurality of computing devices in a similar manner and use this information as a group browsing history to generate network data 116. The network data 116, for instance, may include one or more sequences of network addresses 204.

These sequences may then be used as part of a prediction made by the navigation prediction module 120 to predict a likely next destination for navigation of the communication module 110. For example, the sequences may involve navigation within a website, such as selection of a series of links. Therefore, when navigation of the communication module 110 is monitored as performing similar navigation this sequence may be leveraged to predict a likely next link to be selected by a user. In another example, this navigation may include manual entry of network addresses, selection from a favorites list, and so on, such as to navigate between webpages. Even in this instance, this sequence may be leveraged to predict a likely next destination as part of subsequent navigation to be performed by the communication module 110.

The navigation data 116 may also include one or more navigation rules 206 that may be applied by the navigation prediction module 120 as part of the prediction. A navigation rule 206, for instance, may specify that a link “next page,” if included in content currently accessed by the communication module 110, has a relatively high likelihood of selection by a user. Likewise, other characteristics of currently accessed content may be leveraged by the navigation prediction module 120 as part of making the prediction. The navigation rules 206 may also be applied to a variety of other criteria monitored by the navigation monitoring module, e.g., that a selection of a link “3” is likely after selection of links “1” and “2”, and so on. Thus, in this example the navigation data 116 is provided to the computing device 102 for local usage by the navigation prediction module 120 in making the prediction. Other examples are also contemplated, such as through use by the service provider 104 to predict navigation that is likely to occur by the computing device.

FIG. 3 depicts a system 300 in an example implementation in which a confidence score is leveraged to determine whether the pre-render and/or pre-fetch content from a network address. As illustrated, a navigation monitoring module 112 provides data describing currently monitored navigation 302 performed by the communication module 110 of the computing device 102. As before, this data may describe a currently accessed network address, content obtained via the network address, past navigation, and other characteristics that describe a context of this access.

The navigation prediction module 120 may then employ this data describing currently monitored navigation 302 along with navigation data 116 received from the service provider 102 to make a prediction regarding subsequent navigation. As before, this may be based on a sequence of navigation, characteristics of content, and so on. Further, the navigation prediction module 120 may employ a confidence score calculation module 304 that is representative of functionality to compute a confidence score 306 regarding the prediction. The confidence score 306 may thus be thought of as a computation of how likely the predicted outcome will occur, i.e., subsequent navigation to a particular network address. The may be utilized in a variety of ways.

For example a content retrieval module 308 may obtain the confidence score 306. If the confidence score meets a pre-fetch threshold, content 310 associated with the prediction may be pre-fetched, e.g., obtained via the network. The content 310, for instance, may include text 312, graphics 314, code 316, data describing a layout 318, links 320, and other 322 data. Therefore, this obtained data may be “ready for rendering” but is not in a rendered state that is suitable for display without further processing.

If the confidence score also meets a pre-render threshold, the content 310 obtained via the pre-fetch may be passed to a renderer 324 for processing into a rendered form 326 that is ready for display by a display device. For example, the renderer 324 may parse the layout 318, render vector graphics 314, execute code 316 (e.g., dynamic runtime code), and so on. This processing, for instance, may be performed as part of a graphics processing unit of the computing device 102, although other functionality may also be leveraged as part of this rendering.

Thus, the confidence score may be tied to different amounts of computing device resource usage to improve efficiency of the computing device. As previously described, for instance, pre-rendering of content may be considered a relatively expensive operation in terms of computing device resource usage. Therefore, a pre-rendering threshold may be tied to a relatively high degree of confidence in a prediction before pre-rendering of content is permitted.

However, a pre-fetch of content 310 is not as computationally expensive as a pre-render and therefore a pre-fetch threshold may be employed that is lower than the pre-render threshold to determine whether the content 310 is to be pre-fetched. Thus, in some instances the content may not be fetched at all (e.g., when a confidence score 306 is below a pre-fetch threshold), the content may be pre-fetched but not pre-rendered (e.g., when the confidence score 206 is between the pre-fetch and pre-render thresholds), or the content may be pre-fetched and pre-rendered (e.g., when the confidence score 306 is above a pre-render threshold). Pre-rendering of content may be performed in a variety of ways, an example of which is described as follows and shown in a corresponding figure.

FIG. 4 depicts an example 400 of use of pre-rendered content in a browser of a computing device 102. This example is illustrated using first and second stages 402, 404. At the first stage 402, a tabbed user interface of a browser is shown as outputting a webpage involving pictures of a trip. This webpage is configured as a first webpage of a series of webpages of the trip.

A prediction is made by the navigation prediction module 120 that a second webpage in the series is likely to be the next destination in the user's navigation. This prediction may be performed in a variety of ways as previously described, which in this instance may be based on identification of particular links in the webpage (e.g., next page), identification that multiple links point to a same network address (e.g., “2” and “next page”), and so on.

Accordingly, an “invisible tab” may be allocated which although shown in phantom in the figure is not viewable by a user. Content of the predicted web page may then be rendered to this invisible tab, which may include running dynamic runtime code, rendering graphics, obtaining additional content for other network addresses (e.g., ads), and so on.

Therefore, when a use provide an input to navigate to the predicted content, content in the invisible tab may be used to replace the previous content as shown in the second stage 404. These techniques may continue, e.g., to pre-render a third webpage in the sequence. In this way, a user's subsequent navigation to network addresses may be performed with increased efficiency yet still conserve resources of the computing device. This may be leveraged to support a variety of different functionality, such as to “flip ahead” to additional webpages that are predicted by the computing device. Further discussion of these and other techniques may be found in relation to the following procedures.

Example Procedures

The following discussion describes content pre-render and pre-fetch techniques that may be implemented utilizing the previously described systems and devices. Aspects of each of the procedures may be implemented in hardware, firmware, or software, or a combination thereof. The procedures are shown as a set of blocks that specify operations performed by one or more devices and are not necessarily limited to the orders shown for performing the operations by the respective blocks. In portions of the following discussion, reference will be made to FIGS. 1-4.

FIG. 5 depicts a procedure 500 in an example implementation in which data is collected from a plurality of computing devices and used to generate navigation data that is exposed to predict subsequent navigation. Data is collected from a plurality of computing devices, the data describing navigation performed by respective computing devices to interact with a plurality of network addresses (block 502). Users, for instance, may desire to “opt in” to “flip ahead” features of a browser that support navigation to a next likely webpage through use of a gesture. As a result, data that describes navigation performed by the users may be provided to help predict navigation that may be performed by that user as well as other users.

Navigation data is generated based on the monitored navigation performed by a plurality of different computing devices to access a plurality of different network addresses (block 504). The navigation data 116, for instance, may include network addresses 204, navigation rules 206, and so on.

The navigation data is exposed for use by a computing device to predict subsequent navigation by a computing device to one or more network addresses (block 506). The service provider 104, for instance, may expose the navigation data 116 for use by a computing device 102 is predicting subsequent navigation. Other examples are also contemplated, such as for use by the service provider 104 itself in making the prediction. An example of one technique that may be used to make a prediction may be found below.

FIG. 6 depicts a procedure 600 in an example implementation in which a prediction of a likelihood of subsequent navigation to particular network addresses is utilized to determine whether to pre-fetch and pre-render content available via the particular network address. A likelihood is predicted of subsequent navigation to content associated with a network address based at least in part on monitored navigation performed by a computing device to one or more network addresses (block 602). A navigation prediction module 120, for instance, may leverage navigation data 116 to make a prediction as previously described as to where a communication module 110 is likely to navigate.

A determination is then made whether to cause the computing device to pre-fetch and pre-render the content based at least in part on the prediction (block 604). For example, a confidence score may be computed that indicates a relative likelihood of subsequent navigation to content associated with a network address based at least in part on monitored navigation performed by a computing device to one or more network addresses (block 606).

Responsive to a determination that the confidence score meets a pre-render threshold for the subsequent navigation, the content associated with the network address is caused to be pre-fetched and pre-rendered by the computing device (block 608). Thus, a relatively strong confidence score associated with a prediction may be used as a basis to determine whether to pre-render the content, which as previously described may be computationally expensive.

Responsive to a determination that the confidence score meets a pre-fetch threshold for the subsequent navigation but does not meet the pre-render threshold for the subsequent navigation, the content associated with the network address is caused to be pre-fetched but not pre-rendered by the computing device (block 610). Continuing with the previous example, a determination may be made that although a prediction is likely, it is not likely enough based on the confidence score to assume the expense of pre-rendering the content. Therefore, in this instance the content may be pre-fetched but not pre-rendered, with rendering waiting until a user indicates a desire to navigate to that network address. A variety of other examples are also contemplated as previously described.

Example System and Device

FIG. 7 illustrates an example system 700 that includes the computing device 102 as described with reference to FIG. 1. The example system 700 enables ubiquitous environments for a seamless user experience when running applications on a personal computer (PC), a television device, and/or a mobile device. This environment may be configured to incorporate the techniques previously described, as shown by include of the navigation prediction modules 120. Services and applications run substantially similar in all three environments for a common user experience when transitioning from one device to the next while utilizing an application, playing a video game, watching a video, and so on.

In the example system 700, multiple devices are interconnected through a central computing device. The central computing device may be local to the multiple devices or may be located remotely from the multiple devices. In one embodiment, the central computing device may be a cloud of one or more server computers that are connected to the multiple devices through a network, the Internet, or other data communication link. In one embodiment, this interconnection architecture enables functionality to be delivered across multiple devices to provide a common and seamless experience to a user of the multiple devices. Each of the multiple devices may have different physical requirements and capabilities, and the central computing device uses a platform to enable the delivery of an experience to the device that is both tailored to the device and yet common to all devices. In one embodiment, a class of target devices is created and experiences are tailored to the generic class of devices. A class of devices may be defined by physical features, types of usage, or other common characteristics of the devices.

In various implementations, the computing device 102 may assume a variety of different configurations, such as for computer 702, mobile 704, and television 706 uses. Each of these configurations includes devices that may have generally different constructs and capabilities, and thus the computing device 102 may be configured according to one or more of the different device classes. For instance, the computing device 102 may be implemented as the computer 702 class of a device that includes a personal computer, desktop computer, a multi-screen computer, laptop computer, netbook, and so on.

The computing device 102 may also be implemented as the mobile 704 class of device that includes mobile devices, such as a mobile phone, portable music player, portable gaming device, a tablet computer, a multi-screen computer, and so on. The computing device 102 may also be implemented as the television 706 class of device that includes devices having or connected to generally larger screens in casual viewing environments. These devices include televisions, set-top boxes, gaming consoles, and so on. The techniques described herein may be supported by these various configurations of the computing device 102 and are not limited to the specific examples the techniques described herein.

The cloud 708 includes and/or is representative of a platform 710 for content services 712. The platform 710 abstracts underlying functionality of hardware (e.g., servers) and software resources of the cloud 708. The content services 712 may include applications and/or data that can be utilized while computer processing is executed on servers that are remote from the computing device 102. Content services 712 can be provided as a service over the Internet and/or through a subscriber network, such as a cellular or Wi-Fi network.

The platform 710 may abstract resources and functions to connect the computing device 102 with other computing devices. The platform 710 may also serve to abstract scaling of resources to provide a corresponding level of scale to encountered demand for the content services 712 that are implemented via the platform 710. Accordingly, in an interconnected device embodiment, implementation of functionality of the functionality described herein may be distributed throughout the system 700. For example, the functionality may be implemented in part on the computing device 102 as well as via the platform 710 that abstracts the functionality of the cloud 708.

FIG. 8 illustrates various components of an example device 800 that can be implemented as any type of computing device as described with reference to FIGS. 1, 2, and 7 to implement embodiments of the techniques described herein. Device 800 includes communication devices 802 that enable wired and/or wireless communication of device data 804 (e.g., received data, data that is being received, data scheduled for broadcast, data packets of the data, etc.). The device data 804 or other device content can include configuration settings of the device, media content stored on the device, and/or information associated with a user of the device. Media content stored on device 800 can include any type of audio, video, and/or image data. Device 800 includes one or more data inputs 806 via which any type of data, media content, and/or inputs can be received, such as user-selectable inputs, messages, music, television media content, recorded video content, and any other type of audio, video, and/or image data received from any content and/or data source.

Device 800 also includes communication interfaces 808 that can be implemented as any one or more of a serial and/or parallel interface, a wireless interface, any type of network interface, a modem, and as any other type of communication interface. The communication interfaces 808 provide a connection and/or communication links between device 800 and a communication network by which other electronic, computing, and communication devices communicate data with device 800.

Device 800 includes one or more processors 810 (e.g., any of microprocessors, controllers, and the like) which process various computer-executable instructions to control the operation of device 800 and to implement embodiments of the techniques described herein. Alternatively or in addition, device 800 can be implemented with any one or combination of hardware, firmware, or fixed logic circuitry that is implemented in connection with processing and control circuits which are generally identified at 812. Although not shown, device 800 can include a system bus or data transfer system that couples the various components within the device. A system bus can include any one or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and/or a processor or local bus that utilizes any of a variety of bus architectures.

Device 800 also includes computer-readable media 814, such as one or more memory components, examples of which include random access memory (RAM), non-volatile memory (e.g., any one or more of a read-only memory (ROM), flash memory, EPROM, EEPROM, etc.), and a disk storage device. A disk storage device may be implemented as any type of magnetic or optical storage device, such as a hard disk drive, a recordable and/or rewriteable compact disc (CD), any type of a digital versatile disc (DVD), and the like. Device 800 can also include a mass storage media device 816.

Computer-readable media 814 provides data storage mechanisms to store the device data 804, as well as various device applications 818 and any other types of information and/or data related to operational aspects of device 800. For example, an operating system 820 can be maintained as a computer application with the computer-readable media 814 and executed on processors 810. The device applications 818 can include a device manager (e.g., a control application, software application, signal processing and control module, code that is native to a particular device, a hardware abstraction layer for a particular device, etc.). The device applications 818 also include any system components or modules to implement embodiments of the techniques described herein. In this example, the device applications 818 include an interface application 822 and an input/output module 824 (which may be the same or different as input/output module 114) that are shown as software modules and/or computer applications. The input/output module 824 is representative of software that is used to provide an interface with a device configured to capture inputs, such as a touchscreen, track pad, camera, microphone, and so on. Alternatively or in addition, the interface application 822 and the input/output module 824 can be implemented as hardware, software, firmware, or any combination thereof. Additionally, the input/output module 824 may be configured to support multiple input devices, such as separate devices to capture visual and audio inputs, respectively.

Device 800 also includes an audio and/or video input-output system 826 that provides audio data to an audio system 828 and/or provides video data to a display system 830. The audio system 828 and/or the display system 830 can include any devices that process, display, and/or otherwise render audio, video, and image data. Video signals and audio signals can be communicated from device 800 to an audio device and/or to a display device via an RF (radio frequency) link, S-video link, composite video link, component video link, DVI (digital video interface), analog audio connection, or other similar communication link. In an embodiment, the audio system 828 and/or the display system 830 are implemented as external components to device 800. Alternatively, the audio system 828 and/or the display system 830 are implemented as integrated components of example device 800.

CONCLUSION

Although the example implementations have been described in language specific to structural features and/or methodological acts, it is to be understood that the implementations defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claimed features. 

What is claimed is:
 1. A method comprising: predicting a likelihood of subsequent navigation to content associated with a network address based at least in part on monitored navigation performed by a computing device to one or more network addresses; and determining whether to cause the computing device to pre-fetch and pre-render the content based at least in part on the prediction.
 2. A method as described in claim 1, wherein the one or more network addresses are a current network address accessed by the computing device.
 3. A method as described in claim 1, wherein the predicting includes computing a confidence score and the determining is based at least in part on the confidence score.
 4. A method as described in claim 3, further comprising pre-fetching and pre-rendering the content responsive to a comparison of the confidence score with a pre-render threshold that is indicative of the likelihood of subsequent navigation to the content.
 5. A method as described in claim 4, wherein: the pre-fetching includes obtaining the content from the network address; and the pre-rendering includes parsing an HTML and running dynamic scripts of the obtain content to arrive at a form of the content that is ready for display by a display device of the computing device.
 6. A method as described in claim 5, wherein the pre-rendering is performed in associated with a tab in a user interface that is not visible to a user and further comprising replacing content of a currently viewable tab with the rendered content in the tab responsive to an input to navigate to the network address.
 7. A method as described in claim 4, further comprising pre-fetching the content but not pre-rendering the content responsive to a comparison of the confidence score with a pre-fetch threshold, the pre-fetch threshold indicative of a lower likelihood of the subsequent navigation than a pre-render threshold.
 8. A method as described in claim 1, wherein the predicting is performed using one or more rules.
 9. A method as described in claim 8, wherein at least one of the rules is configured to identify a type of link included in content to be used as a basis for the prediction but not a particular network address associated with the link.
 10. A method as described in claim 8, wherein the one or more rules are received from a network service, the one or more rules generated based on data described monitored navigation performed by a plurality of different computing devices.
 11. A method as described in claim 1, wherein the monitored navigation describes a sequence of network addresses that have been accessed by the computing device.
 12. A method as described in claim 1, wherein the predicting and the determining are performed locally by the computing device.
 13. A system comprising: one or more modules implemented at least partially in hardware, the one or more modules configured to perform operations comprising: computing a confidence score indicating a relative likelihood of subsequent navigation to content associated with a network address based at least in part on monitored navigation performed by a computing device to one or more network addresses; responsive to a determination that the confidence score meets a pre-render threshold for the subsequent navigation, causing the content associated with the network address to be pre-fetched and pre-rendered by the computing device; and responsive to a determination that the confidence score meets a pre-fetch threshold for the subsequent navigation but does not meet the pre-render threshold for the subsequent navigation, causing the content associated with the network address to be pre-fetched but not pre-rendered by the computing device.
 14. A system as described in claim 13, wherein the computing is performed using one or more rules that is configured to identify a type of link included in content to be used as a basis for the prediction but not a particular network address associated with the link or are generated based on data described monitored navigation performed by a plurality of different computing devices.
 15. A system as described in claim 13, wherein: the pre-fetching includes obtaining the content from the network address; and the pre-rendering includes parsing an HTML and running dynamic scripts of the obtain content to arrive at a form of the content that is ready for display by a display device of the computing device.
 16. A system as described in claim 13, wherein the one or more modules are accessible via a network by the computing device.
 17. A system comprising: one or more modules implemented at least partially in hardware, the one or more modules configured to perform operations comprising: generating navigation data based on monitored navigation performed by a plurality of different computing devices to access a plurality of different network addresses; and exposing the navigation data for use by a computing device to predict subsequent navigation by the computing device to one or more network addresses, at least part of the predicted navigation not involving a link included in a current content item accessed by the computing device.
 18. A system as described in claim 17, wherein the navigation data includes one or more rules that include a rule configured to identify a type of link included in content to be used as a basis for the prediction but not a particular network address associated with the link or a rule generated based on data described monitored navigation performed by a plurality of different computing devices.
 19. A system as described in claim 17, wherein the prediction of the subsequent navigation by the computing device is performed as part of a determination of whether to pre-render content associated with the subsequent navigation by the computing device.
 20. A system as described in claim 17, wherein the prediction of the subsequent navigation by the computing device is performed as part of a determination of whether to pre-fetch content associated with the subsequent navigation by the computing device. 